1. Field of the Invention
The present invention relates to a method and apparatus for enhancing the signaling between a mobile communication device and a network. Specifically, the present invention is directed to a method and apparatus for providing new configurations for transmitting control information between a mobile terminal, for example user equipment (UE), and a radio network controller (RNC) using a common control channel (CCCH) logical channel/transport channel.
2. Discussion of the Related Art
The universal mobile telecommunications system (UMTS) is a European-type, third generation IMT-2000 mobile communication system that has evolved from a European standard known as Global System for Mobile communications (GSM). UMTS is intended to provide an improved mobile communication service based upon a GSM core network and wideband code division multiple access (W-CDMA) wireless connection technology.
In December 1998, the ETSI of Europe, the ARIB/TTC of Japan, the T1 of the United States, and the TTA of Korea formed a Third Generation Partnership Project (3GPP). The 3GPP creates detailed specifications of UMTS technology.
In order to achieve rapid and efficient technical development of the UMTS, five technical specification groups (TSG) have been created within the 3GPP for standardizing the UMTS by considering the independent nature of the network elements and their operations. Each TSG develops, approves, and manages the standard specification within a related region. Among these groups, the radio access network (RAN) group (TSG-RAN) develops the standards for the functions, requirements, and interface of the UMTS terrestrial radio access network (UTRAN), which is a new radio access network for supporting W-CDMA access technology in the UMTS.
A conventional UMTS network structure 1 is illustrated in FIG. 1. One mobile terminal 2, or user equipment (UE), is connected to a core network 4 through a UMTS terrestrial radio access network (UTRAN) 6. The UTRAN 6 configures, maintains, and manages a radio access bearer for communications between the UE 2 and core network 4 to meet end-to-end quality-of-service requirements.
The UTRAN 6 consists of at least one radio network subsystem 8, including one RNC 10 acting as an access point to the core network 4, and at least one Node B 12 managed by a corresponding RNC. The RNCs 10 are logically classified as controlling RNCs, which allocate and manage common radio resources for a plurality of UEs 2 of a cell, and serving RNCs, which allocate and manage dedicated radio resources for a specific UE 2 of a cell. Each Node B 12 manages at least one cell.
The core network 4 may be divided according to the type of service provided, namely, a circuit-switched (CS) domain and a packet-switched (PS) domain. For example, a general voice conversation service is a circuit switched (CS) service, while a Web browsing service via an Internet connection is classified as a packet switched (PS) service.
The CS domain includes a mobile switching center (MSC) 14 acting as an access point to the UTRAN 6 and a gateway mobile switching center (GMSC) 16 acting as an access point to an external network. The PS domain includes a serving GPRS support node (SGSN) 18 acting as an access point to the UTRAN 6 and a gateway GPRS support node (GGSN) 20 acting as an access point to the external network. A visitor location register (VLR) 22 and a home location register (HLR) 24 manage user registration information.
In the CS domain, the access point of the core network 4 is the MSC 14 via an lu-CS interface. For supporting circuit switched services, the RNCs 10 are connected to the MSC 14 of the core network 4 and the MSC is connected to the GMSC 16 that manages the connection with other networks.
In the PS domain, the access point of the core network 4 is the SGSN 18 via an lu-PS interface. For supporting packet switched services, the RNCs 10 are connected to the SGSN 18 and the GGSN 20 of the core network 4. The SGSN 18 supports the packet communications with the RNCs 10 and the GGSN 20 manages the connection with other packet switched networks, such as the Internet.
The interface between the UE 2 and UTRAN 6 is realized through a radio interface protocol established in accordance with 3GPP radio access network specifications. The conventional architecture of the radio interface protocol is illustrated in FIG. 2.
As illustrated in FIG. 2, the conventional radio interface protocol has horizontal layers comprising a physical layer (L1), a data link layer (L2), and a network layer (L3), and has vertical planes comprising a user plane (U-plane) for transmitting user data and a control plane (C-plane) for transmitting control information. The user plane is a region that handles traffic information with the user, such as voice or Internet protocol (IP) packets. The control plane is a region that handles control information for an interface with a network and maintenance and management of a call.
The protocol layers may be divided into a first layer (L1), a second layer (L2), and a third layer (L3) based on the three lower layers of an open system interconnection (OSI) standard model. The first layer (L1) is the physical layer. The second layer (L2) includes a medium access control (MAC) layer, a radio link control (RLC) layer, a broadcast/multicast control (BMC) layer, and a packet data convergence protocol (PDCP) layer.
The physical (PHY) layer provides information transfer service to a higher layer by using various radio transfer techniques. The physical layer is linked via transport channels to a medium access control (MAC) layer.
The MAC layer handles mapping between logical channels and transport channels and provides allocation of the MAC parameters for allocation and re-allocation of radio resources. The MAC layer is connected to the physical layer by transport channels and may be divided into a MAC-b sub-layer, a MAC-d sub-layer, a MAC-c/sh sub-layer, and a MAC-hs sub-layer according to the type of transport channel being managed.
The MAC layer is connected to an upper layer called the radio link control (RLC) layer, via a logical channel. Various logical channels are provided according to the type of information transmitted. In general, a control channel is used to transmit information of the control plane and a traffic channel is used to transmit information of the user plane.
A logical channel may be a common channel or a dedicated channel depending on whether the logical channel is shared. Logical channels include a dedicated traffic channel (DTCH), a dedicated control channel (DCCH), a common traffic channel (CTCH), a common control channel (CCCH), a broadcast control channel (BCCH), and a paging control channel (PCCH), or a Shared Channel Control Channel. The BCCH provides information including information utilized by a UE 2 to access the core network 4. The PCCH is used by the UTRAN 6 to access a UE 2. The different logical channels are listed in FIG. 3.
The MAC-b sub-layer manages a BCH (Broadcast Channel), which is a transport channel handling the broadcasting of system information. In the downlink, the MAC-c/sh sub-layer manages a common transport channel, such as a forward access channel (FACH) or a downlink shared channel (DSCH), which is shared by a plurality of terminals. In the uplink, the MAC-c/sh sub-layer manages a Radio Access Channel (RACH). Therefore, each UE 2 has one MAC-c/sh entity.
The possible mapping between the logical channels and the transport channels from the perspective of a UE 2 is illustrated in FIG. 4. The possible mapping between the logical channels and the transport channels from the perspective of a UTRAN 6 is illustrated in FIG. 5.
The MAC-d sub-layer manages a dedicated channel (DCH), which is a dedicated transport channel for a UE 2. The MAC-d sublayer is located in a serving RNC 10 (SRNC) that manages a corresponding UE 2, and one MAC-d sublayer also exists in each UE 2.
The RLC layer, depending of the RLC mode of operation, supports reliable data transmissions and performs segmentation and concatenation on a plurality of RLC service data units (SDUs) delivered from an upper layer. When the RLC layer receives the RLC SDUs from the upper layer, the RLC layer adjusts the size of each RLC SDU in an appropriate manner based upon processing capacity and then creates data units by adding header information thereto.
The data units, called protocol data units (PDUs), are transferred to the MAC layer via a logical channel. The RLC layer includes a RLC buffer for storing the RLC SDUs and/or the RLC PDUs. The RLC services are used by service-specific protocol layers on the user plane, namely a broadcast/multicast control (BMC) protocol and a packet data convergence protocol (PDCP), and are used by a radio resource control (RRC) layer for signaling transport on the control plane.
The BMC layer schedules a cell broadcast (CB) message delivered from the core network 4 and enables the CB message to be broadcast to the corresponding UEs 2 in the appropriate cell. Header information, such as a message identifier, a serial number, and a coding scheme, is added to the CB message to generate a BMC message for delivery to the RLC layer.
The RLC layer appends RLC header information and transmits the thus-formed message to the MAC layer via a common traffic channel as a logical channel. The MAC layer maps the common traffic channel to a forward access channel (FACH) as a transport channel. The transport channel is mapped to a secondary common control physical channel as a physical channel.
The PDCP layer is located above the RLC layer. The PDCP layer is used to transmit network protocol data, such as the IPv4 or IPv6, effectively on a radio interface with a relatively small bandwidth. For this purpose, the PDCP layer reduces unnecessary control information used in a wired network, a function called header compression.
The radio resource control (RRC) layer located at the lowest portion of the third layer (L3) is only defined in the control plane. The RRC layer handles the control plane signaling of the network layer (L3) between the UEs 2 and the UTRAN 6 and controls the transport and physical channels for the establishment, reconfiguration, and release of radio bearers. A radio bearer is a service provided by a lower layer, such as the RLC layer or MAC layer, for data transfer between the UE 2 and UTRAN 6.
The air interface (Uu) between the UE 2 and the UTRAN 6 includes the RRC layer for the establishment, reconfiguration, and release of radio bearers, for example a service providing data transfer between the UE and an RNC 10 of the UTRAN. Establishment of a radio bearer determines the regulating characteristics of the protocol layer and channel needed to provide a specific service, thereby establishing the parameters and operational methods of the service.
A UE 2 is said to be in the RRC-connected mode when the RRC layer of a UE and the RRC layer of a corresponding RNC 10 are connected, thereby providing for bi-directional transfer of RRC messages. If there is no RRC connection, the UE 2 is said to be in the RRC-idle mode.
Upon power-up, a UE 2 is in the RRC-idle mode by default. When necessary, an RRC-idle UE 2 transitions to the RRC-connected mode through an RRC connection procedure.
An RRC connection is established, for example, when uplink data transfer is needed to make a call or to respond to a paging message from the RNC 10. The RRC connection connects the UE 2 to the RNC 10 of the UTRAN 6.
The different possibilities that exist for the mapping between the radio bearers and the transport channels are not all possible all the time. The UE 2 and UTRAN 6 deduce the possible mapping depending on the UE state and the procedure that the UE and UTRAN are executing.
The different transport channels are mapped onto different physical channels. For example, the RACH transport channel is mapped on a given PRACH, the DCH may be mapped on the DPCH, the FACH and the PCH may be mapped on the S-CCPCH, and the DSCH is mapped on the PDSCH. The configuration of the physical channels is determined by RRC signaling exchange between the RNC 10 and the UE 2.
Because an RRC connection exists for UEs 2 in RRC connected mode, the UTRAN 6 can determine the existence of a particular UE within the unit of cells, for example in which cell or set of cells the RRC connected mode UE resides, and which physical channel the UE is monitoring. Therefore, the UE 2 can be effectively controlled.
In contrast, the UTRAN 6 cannot determine the existence of a UE 2 in idle mode. The existence of idle UEs 2 can only be determined by the core network 4 to be within a region that is larger than a cell, for example a location or a routing area. Therefore, the existence of idle mode UEs 2 is determined within large regions, and, in order to receive mobile communication services such as voice or data, the idle mode UE must transition into the RRC connected mode. The possible transitions between modes and states are illustrated in FIG. 6.
A UE 2 in RRC connected mode may be in different states, for example CELL_FACH state, CELL_PCH state, CELL_DCH state or URA_PCH state. Depending on the state, the UE 2 performs different actions and monitors different channels.
For example a UE 2 in CELL_DCH state will attempt to monitor, among others, a DCH type of transport channel that is mapped to a certain DPCH. A UE 2 in CELL_FACH state will monitor several FACH transport channels that are mapped to a certain S-CCPCH. A UE 2 in CELL_PCH state will monitor the PICH channel and the PCH channel that is mapped to a certain S-CCPCH physical channel.
The actions of a UE 2 are also different depending on the state. For example a UE 2 is in CELL_FACH state whenever it moves from one cell into another cell and, depending on different conditions, the UE will start the CELL Update procedure by transmitting a Cell Update message to the Node B 12 to indicate that the UE has changed location and will begin monitoring the FACH channel. This procedure is also performed when the UE 2 transitions from any other state to CELL_FACH state and the UE has no C-RNTI available, for example when transitioning from CELL_PCH state or CELL_DCH state, or when a UE in CELL_FACH state was previously out of a coverage area.
In order to distinguish transmissions between the RNC 10 and the different UEs 2 and in order to distinguish the different radio bearers that may be multiplexed in the MAC layer, the MAC includes a header in the transmissions. The logical channel type determines the type of MAC header that the UE 2 uses to transmit the message, the UMTS mode (FDD or TDD) and the transport channel to which the logical channel is mapped. This header may contain an identifier that identifies a specific UE 2.
There are different identifiers used in the MAC header to distinguish transmissions to/from the different UEs 2. The RNC 10 allocates the different identifiers.
Examples of identifiers are C-RNTI, U-RNTI, S-RNTI and H-RNTI. C-RNTI is used to identify a given UE 2 in a given cell. U-RNTI is used to identify a UE 2 in a given UTRAN 6 system. S-RNTI identifies the UE 2 on a DSCH transport channel. H-RNTI identifies the UE 2 on a given HSDPA transport channel.
The fields that are contained in the MAC header for all transport channels except the HS-DSCH transport channel are illustrated in FIG. 7. The TCTF (Target Channel Type Field) field indicates the type of logical channel that is mapped on the given transport channel in the event different logical channels may be mapped on the transport channel. The UE-Id type is the UE 2 identifier. The C/T field indicates the radio bearer that was established.
The TCTF is utilized to distinguish between the different logical channels. Distinguishing between logical channels determines the exact format of the rest of the MAC header. For example, If the CCCH is mapped on RACH/FACH, the MAC header contains only the TCTF field that carries the information that the rest of the MAC PDU contains a message from a CCCH type transport channel.
Presently, the UMTS standard indicates that only the signaling radio bearer 0 (SRB0) may use the CCCH logical channel. Therefore there is no need for the C/T field when the CCCH logical channel is used.
In the uplink, not all transport channels are available depending upon the state of the UE 2. For example when the UE 2 is in CELL_FACH state, the UE cannot use a DCH transport channel, but may use, for example, a RACH transport channel.
For the mapping of DCCH on RACH, for example, the UE 2 must have a valid C-RNTI. However, if the UE 2 has just moved into a new cell and desires to start the Cell Update procedure, the UE does not have a valid C-RNTI. Therefore, the UE 2 may only map the CCCH logical channel on the RACH. In coding the CCCH message, an “initial Identity,” which is either fixed or allocated to the UE 2 by the core network 4, or the U-RNTI is included in the message to distinguish the UE 2.
The same situation exists when the UE 2 has just been powered on and wants to establish an RRC connection. Therefore, the UE 2 may only use CCCH logical channel mapped on the RACH transport channel to transmit the RRC Connection Request message.
The RLC layer may use either transparent mode (TM), unacknowledged mode (UM) or acknowledged mode (AM). Depending upon the mode, the size of the RLC PDUs may change after each transmission of a transport block. In TM and UM mode, the size of the RLC PDUs may change after each transmission. In AM, the PDU size may not be changed dynamically, but only through a reconfiguration by the RNC 10, because the PDUs might be retransmitted.
The transport channels may handle RLC PDUs of predefined sizes. The transport block size of the physical layer is defined by the RLC PDU size and the MAC header size. Different transport channels allow different transport block sizes and a given transport channel may also allow different sizes. Generally, the transport block sizes a UE 2 is allowed to use for a specific radio bearer are determined by the RNC 10 or fixed by the UMTS standard.
A transport channel is defined by its type, for example RACH, FACH, DCH, DSCH or USCH, and by its attributes. Some attributes are dynamic and some attributes are semi-static.
Dynamic attributes include the transport block size, which is the size of the MAC PDU; the transport block set size, which is the size of the MAC PDU multiplied by the number of MAC PDUs that can be transported in one transmission time interval (TTI); and the transmission time interval, which is an optional dynamic attribute for TDD only. Semi-static attributes include the transmission time interval, which is mandatory for FDD and optional for the dynamic part of TDD NRT bearers; the error protection scheme applied; the type of error protection; the turbo code; the convolutional code; no channel coding, which is semi-static for TDD only; the coding rate; the static rate matching parameter; and the size of CRC.
The semi static part of an attribute may only be changed when the RRC layer changes the configuration. The dynamic part of an attribute provides several alternatives, for example that there may be one, two or three transport blocks transmitted in one TTI. Furthermore, the transport block size may be changed during each TTI.
A set of values of the dynamic and the semi-static parts is called a transport format (TF). Each transport channel may use one or more transport formats. For example, only one transport channel may be mapped on the Physical Random Access Channel (PRACH), the channel to which the present invention is directed.
The PRACH message includes a data portion that is generated out of the transport block set received by the MAC layer and includes control information that is generated in the Physical layer. The control information includes the transport format combination indicator (TFCI) that is used to determine the coding and the transport format that is used for the transmission. FIG. 8 illustrates the RACH message structure.
When a radio bearer is mapped via a logical channel to a transport channel, not all existing transport format combinations may be used. The allowable transport format combinations are determined by the RRC protocol, as indicated by the RB mapping information.
Presently, the UMTS standard indicates that signaling radio bearer number 0 (SRB0) is always mapped via a CCCH logical channel on the RACH transport channel. Presently, the UMTS standard also indicates that a UE2 is only allowed to use the first transport format that is listed for the selected RACH for transmission of messages via CCCH.
Generally, the first transport format of a RACH may carry only one transport block of 168 bits. However, the messages that are transmitted via the CCCH may be large and, in some situations, it may be beneficial to use also other transport block sizes.
The CCCH is fixed to always use TM mode in the uplink. TM mode does not support segmentation and padding. The MAC header always includes only the TCTF header, which consists of 2 bits. Therefore, the RRC message that is carried in the MAC SDU must be adapted to meet the required size of the MAC SDU.
RRC messages are generated using a special coding known as ASN. 1 coding. FIG. 9 illustrates ASN. 1 coding of an RRC message for CCCH.
The different information elements that form the R99 part and the extension part are encoded by the means of the ASN. 1 to create the basic production. The encoder adds padding bits to ensure that the number of bits is a multiple of 8. In order to adapt the RRC PDU size to the size of the MAC-SDU for the CCCH messages on TM, the RRC layer adds additional padding.
The CCCH logical channel is used to transmit Cell Update messages, RRC connection request messages and URA update messages in the uplink. The messages have different sizes depending upon the information that is added to the message. The messages also contain information on the measured results of neighboring cells, for example quality and timing information such as measured results on RACH.
Conventional methods adapt the size of the messages transmitted on the CCCH logical channel so that the RLC PDU with the MAC header fits inside the transport block that is used in the RACH. A conventional method 1 for transmitting messages on the CCCH logical channel is illustrated in FIG. 10.
As illustrated in FIG. 10, information regarding the existing PRACH configurations is transmitted to a UE 2 (S10). Based on the existing transport PRACH configurations, the UE 2 selects the PRACH according to an algorithm (S12). The UE 2 generates a message including all information elements for transmission over the PRACH (S14). The UE 2 compares the message size with the transport block size of the first transport format of the corresponding RACH and adapts the message size by deleting measurement information until the message fits within the transport block size (S16). The UE 2 then transmits the adapted message via the PRACH (S18).
In a UMTS system several PRACHs may be configured in a cell. A UE 2 in RRC-idle or RRC-connected mode reads a list of PRACH channels from the system information blocks. Each PRACH channel may have a list of available transport formats.
In TDD (Time Division Duplex), the TTI (Transmission Time Interval), or duration of the transmission of a transport block, of a PRACH may be different depending on the transport format. In 1.28 MCPS TDD mode, the UE 2 always selects the largest TTI of the transport formats that are suitable for transmission of the transport block set.
In FDD (Frequency Division Duplex), each PRACH channel has a fixed TTI. Each transport format is characterized, among other characteristics, by a transport block size and the number of transport blocks that may be transmitted during one TTI.
In order to select the PRACH, the UE 2 first must select the TTI to be applied. Once the TTI is selected, the UE 2 selects one PRACH channel randomly from the PRACHs that exist that use the selected TTI length. If PRACHs with different TTI lengths exist, the TTI length is selected according to the method 50 illustrated in FIG. 11. Otherwise, the TTI of the configured PRACHs is utilized.
Referring to FIG. 11, the UE 2 selects a transport format with 10 msec. TTI based on the available transport formats in step S52. From the transport formats supported by all RACHs, those formats that have a TTI of 10 msec. and correspond to a single transport block of all configured RLC sizes are kept.
For example, the RLC size applicable for RB0 is kept in RRC-idle mode and the RLC sizes configured with explicit RB mapping information are kept in RRC-connected mode. If more than a single transport format is applicable, the UE 2 may select any of the available formats.
Preferably, the UE 2 selects the transport format that is intended for use by the next transmission. If such information is not available, the transport format corresponding to the largest configured RLC size is selected.
In step S54, the UE 2 calculates the power margin by estimating the transmit power necessary to transmit a transport block set on the RACH with a given transport format. The algorithm used for this calculation is specified by the 3GPP standard and uses, among other input parameters, the TTI, the transport block size and the number of transport blocks to be transmitted.
In step S56, the calculated power margin is compared to 6 dB. If the power margin is greater than 6 dB, the 10 msec. TTI is selected in step S58. If the calculated power margin is not greater than 6 db, the 20 msec. TTI is selected in step S60.
If the size of a CCCH message is too large using the conventional methods 1, 50, a UE2 might completely delete the information on the measured results of neighboring cells, for example measured results on RACH, even though the quality and timing information might be needed in the RNC 10. Without the quality and timing information, a connection may not be established with the RNC 10 when a UE 2 moves to another cell. The UE 2 may not be able to transmit data and a current call may be interrupted or a new call may not be initiated.
Because the UMTS standard restricts a UE 2 to always use the first transport block size of the selected PRACH, there is only one transport block size available for SRB0. Therefore, the size of the messages is limited to the size of the transport block.
It has been suggested to change the size of the first transport format of the PRACH. However, there is no guarantee that all mobiles terminals will support a size change of the SRB0. Therefore, as long as there are mobile terminals that do not support another transport block size used in the PRACH, messages that are transmitted via the CCCH in the uplink may not be extended in new Releases of the UMTS standard.
Therefore, there is a need for a method and apparatus that conforms to a new UMTS standard that allows messages to be transmitted via the CCCH channel that are larger than the currently available transport block size, while not impacting the operation of mobile terminals that do not conform to the new UMTS standard. The present invention addresses these and other needs.